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Abstract 


The IETF policies about Intellectual Property Rights (IPR), such as 
patent rights, relative to technologies developed in the IETF are 
designed to ensure that IETF working groups and participants have as 
much information about any IPR constraints on a technical proposal as 
possible. The policies are also intended to benefit the Internet 
community and the public at large, while respecting the legitimate 
rights of IPR holders. This memo details the IETF policies 
concerning IPR related to technology worked on within the IETF. It 
also describes the objectives that the policies are designed to meet. 
This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of 
RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 
2028, for all purposes, including reference [2] in RFC 2418. 
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1. Definitions 


The following definitions are for terms used in the context of this 
Other terms, including "IESG," "ISOC," "IAB," and "RFC 


document. 
Editor," 


a. “IETF": 


lists, 


are defined in [RFC 2028]. 


In the context of this document, the IETF includes all 
individuals who participate in meetings, working groups, mailing 
functions and other activities which are organized or 
initiated by ISOC, the IESG or the IAB under the general 
designation of the Internet Engineering Task Force or IETF, but 
solely to the extent of such participation. 


b. “IETF Standards Process": the activities undertaken by the IETF in 
any of the settings described in 1(c) below. 


c. "IETF Contribution": any submission to the IETF intended by the 

Contributor for publication as all or part of an Internet-Draft or 
(except for RFC Editor Contributions described below) and any 
statement made within the context of an IETF activity. Such 
statements include oral statements in IETF sessions, as well as 
written and electronic communications made at any time or place, 
which are addressed to: 


RFC 


0000 


Bradner 


the 
any 
the 
the 


IETF 
IETF 


IESG, 


plenary session, 
working group or portion thereof, 
or any member thereof on behalf of the IESG, 


IAB or any member thereof on behalf of the IAB, 
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o any IETF mailing list, including the IETF list itself, any 
working group or design team list, or any other list 
functioning under IETF auspices, 

o the RFC Editor or the Internet-Drafts function (except for RFC 
Editor Contributions described below). 


Statements made outside of an IETF session, mailing list or other 
function, that are clearly not intended to be input to an IETF 
activity, group or function, are not IETF Contributions in the 
context of this document. 


d. "Internet-Draft": temporary documents used in the IETF and RFC 
Editor processes. Internet-Drafts are posted on the IETF web site 
by the IETF Secretariat and have a nominal maximum lifetime in the 
Secretariat’s public directory of 6 months, after which they are 
removed. Note that Internet-Drafts are archived many places on 
the Internet, and not all of these places remove expired 
Internet-Drafts. Internet-Drafts that are under active 
consideration by the IESG are not removed from the Secretariat’s 
public directory until that consideration is complete. In 
addition, the author of an Internet-Draft can request that the 
lifetime in the Secretariat’s public directory be extended before 
the expiration. 


e. "RFC": the basic publication series for the IETF. RFCs are 
published by the RFC Editor and once published are never modified. 
(See [RFC 2026] Section 2.1) 


f. "RFC Editor Contribution": An Internet-Draft intended by the 
Contributor to be submitted to the RFC Editor for publication as 
an Informational or Experimental RFC but not intended to be part 
of the IETF Standards Process. 


g. “IETF Internet-Drafts": Internet-Drafts other than RFC Editor 
Contributions. Note that under Section 3.3(a) the grant of rights 
in regards to IETF Internet-Drafts as specified in this document 
is perpetual and irrevocable and thus survives the Secretariat’s 
removal of an Internet-Draft from the public directory, except as 
limited by Section 3.3(a) (C). (See [RFC 2026] Sections 2.2 and 8) 


h. “IETF Documents": RFCs and Internet-Drafts except for Internet- 
Drafts that are RFC Editor Contributions and the RFCs that are 
published from them. 


i. "RFC Editor Documents": RFCs and Internet-Drafts that are RFC 
Editor Contributions and the RFCs that may be published from them. 


j. "Contribution": IETF Contributions or RFC Editor Contributions 
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k. "Contributor": an individual submitting a Contribution 


1. "Reasonably and personally known": means something an individual 
knows personally or, because of the job the individual holds, 
would reasonably be expected to know. This wording is used to 
indicate that an organization cannot purposely keep an individual 
in the dark about patents or patent applications just to avoid the 
disclosure requirement. But this requirement should not be 
interpreted as requiring the IETF Contributor or participant (or 
his or her represented organization, if any) to perform a patent 
search to find applicable IPR. 


m. "Implementing Technology": means a technology that implements an 
IETF specification or standard. 


n. "Covers" or "Covered" mean that a valid claim of a patent ora 
patent application in any jurisdiction or a protected claim, or 
any other Intellectual Property Right, would necessarily be 
infringed by the exercise of a right (e.g., making, using, 
selling, importing, distribution, copying, etc.) with respect to 
an Implementing Technology. For purposes of this definition, 
"valid claim" means a claim of any unexpired patent or patent 
application which shall not have been withdrawn, cancelled or 
disclaimed, nor held invalid by a court of competent jurisdiction 
in an unappealed or unappealable decision. 


Oo. "IPR" or "Intellectual Property Rights": means patent, copyright, 
utility model, invention registration, database and data rights 
that may Cover an Implementing Technology, whether such rights 
arise from a registration or renewal thereof, or an application 
therefore, in each case anywhere in the world. 


2. Introduction 


In the years since RFC 2026 was published there have been a number of 
times when the exact intent of Section 10, the section which deals 
with IPR disclosures has been the subject of vigorous debate within 
the IETF community. This is because it is becoming increasingly 
common for IETF working groups to have to deal with claims of 
Intellectual Property Rights (IPR), such as patent rights, with 
regards to technology under discussion in working groups. The aim of 
this document is to clarify various ambiguities in Section 10 of [RFC 
2026] that led to these debates and to amplify the policy in order to 
clarify what the IETF is, or should be, doing. 


IPR disclosures can come at any point in the IETF Standards Process, 
e.g., before the first Internet-Draft has been submitted, prior to 
RFC publication, or after an RFC has been published and the working 
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group has been closed down; they can come from people submitting 
technical proposals as Internet-Drafts, on mailing lists or at 
meetings, from other people participating in the working group or 
from third parties who find out that the work is going or has gone 
on; and they can be based on granted patents or on patent 
applications, and in some cases be disingenuous, i.e., made to affect 
the IETF Standards Process rather than to inform. 


RFC 2026, Section 10 established three basic principles regarding the 
IETF dealing with claims of Intellectual Property Rights: 


(a) the IETF will make no determination about the validity of any 
particular IPR claim 

(b) the IETF following normal processes can decide to use technology 
for which IPR disclosures have been made if it decides that such 
a use is warranted 

(c) in order for the working group and the rest of the IETF to have 
the information needed to make an informed decision about the use 
of a particular technology, all those contributing to the working 
group’s discussions must disclose the existence of any IPR the 
Contributor or other IETF participant believes Covers or may 
ultimately Cover the technology under discussion. This applies 
to both Contributors and other participants, and applies whether 
they contribute in person, via email or by other means. The 
requirement applies to all IPR of the participant, the 
participant’s employer, sponsor, or others represented by the 
participants, that is reasonably and personally known to the 
participant. No patent search is required. 


Section 1 defines the terms used in this document. Sections 3, 4 and 
5 of this document address the intellectual property issues 
previously addressed by Section 10 of RFC 2026. Sections 6 thru 12 
then explain the rationale for these provisions, including some of 
the clarifications that have been made since the adoption of RFC 
2026. The rules and procedures set out in this document are not 
intended to modify or alter the IETF’s current policy toward IPR in 
the context of the IETF Standards Process. They are intended to 
clarify and fill in procedural gaps. 


A companion document [RFC 3667] deals with rights (such as copyrights 
and trademarks) in Contributions, including the right of IETF and its 
participants to publish and create derivative works of those 
Contributions. This document is not intended to address those 
issues. 
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This document is not intended as legal advice. Readers are advised 
to consult their own legal advisors if they would like a legal 
interpretation of their rights or the rights of the IETF in any 
Contributions they make. 


3. Contributions to the IETF 
3.1. General Policy 


In all matters of Intellectual Property Rights, the intent is to 
benefit the Internet community and the public at large, while 
respecting the legitimate rights of others. 


3.2. Rights and Permissions 
3.2.1. All Contributions 


By submission of a Contribution, each person actually submitting the 
Contribution, and each named co-Contributor, is deemed to agree to 
the following terms and conditions, on his or her own behalf, and on 
behalf of the organizations the Contributor represents or is 
sponsored by (if any) when submitting the Contribution. 


A. The Contributor represents that he or she has made or will 
promptly make all disclosures required by Section 6.1.1 of this 
document. 


B. The Contributor represents that there are no limits to the 
Contributor’s ability to make the grants, acknowledgments and 
agreements herein that are reasonably and personally known to the 
Contributor. 


C. If the Contribution is an Internet-Draft, this agreement must be 
acknowledged, by including in the "Status of this Memo" section on 
the first page of the Contribution, the appropriate notices 
described in Section 5 of [RFC 3667]. 


4. Actions for Documents for which IPR Disclosure(s) Have Been Received 


(A) When any Intellectual Property Right is disclosed before 
publication as an RFC, with respect to any technology or 
specification, described in a Contribution in the manner set 
forth in Section 6 of this document, the RFC Editor shall ensure 
that the document include a note indicating the existence of such 
claimed Intellectual Property Rights in any RFC published from 
the Contribution. (See Section 5 below.) 
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(B) The IESG disclaims any responsibility for identifying the 
existence of or for evaluating the applicability of any IPR, 
disclosed or otherwise, to any IETF technology, specification or 
standard, and will take no position on the validity or scope of 
any such IPR claims. 


(C) Where Intellectual Property Rights have been disclosed for IETF 
Documents as provided in Section 6 of this document, the IETF 
Executive Director shall request from the discloser of such IPR, 
a written assurance that upon approval by the IESG for 
publication as RFCs of the relevant IETF specification(s), all 
persons will be able to obtain the right to implement, use, 
distribute and exercise other rights with respect to Implementing 
Technology under one of the licensing options specified in 
Section 6.5 below unless such a statement has already been 
submitted. The working group proposing the use of the technology 
with respect to which the Intellectual Property Rights are 
disclosed may assist the IETF Executive Director in this effort. 


The results of this procedure shall not, in themselves, block 
publication of an IETF Document or advancement of an IETF 
Document along the standards track. A working group may take 
into consideration the results of this procedure in evaluating 
the technology, and the IESG may defer approval when a delay may 
facilitate obtaining such assurances. The results will, however, 
be recorded by the IETF Executive Director, and be made available 
online. 


4.1. No Determination of Reasonable and Non-discriminatory Terms 


The IESG will not make any explicit determination that the assurance 
of reasonable and non-discriminatory terms or any other terms for the 
use of an Implementing Technology has been fulfilled in practice. It 
will instead apply the normal requirements for the advancement of 
Internet Standards. If the two unrelated implementations of the 
specification that are required to advance from Proposed Standard to 
Draft Standard have been produced by different organizations or 
individuals, or if the "Significant implementation and successful 
operational experience" required to advance from Draft Standard to 
Standard has been achieved, the IESG will presume that the terms are 
reasonable and to some degree non-discriminatory. (See RFC 2026, 
Section 4.1.3.) Note that this also applies to the case where 
multiple implementers have concluded that no licensing is required. 
This presumption may be challenged at any time, including during the 
Last-—Call period by sending email to the IESG. 
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5. 


6. 


Notice to be included in RFCs 


The RFC Editor will ensure that the following notice is present in 
all IETF RFCs and all other RFCs for which an IPR disclosure or 
assertion has been received prior to publication. 


Disclaimer of validity: 


"The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to rights 
in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use 
of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository 
at http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights that may cover technology that may be required 
to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org." 


IPR Disclosures 


This section discusses aspects of obligations associated with IPR 
disclosure. 


This document refers to the IETF participant making disclosures, 
consistent with the general IETF philosophy that participants in the 
IETF act as individuals. A participant’s obligation to make a 
disclosure is also considered satisfied if the IPR owner or the 
participant’s employer or sponsor makes an appropriate disclosure in 
place of the participant doing so. 
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6.1. Who must make an IPR disclosure? 
6.1.1. A Contributor’s IPR in his or her Contribution 


Any Contributor who reasonably and personally knows of IPR meeting 
the conditions of Section 6.6 which the Contributor believes Covers 
or may ultimately Cover his or her Contribution, or which the 
Contributor reasonably and personally knows his or her employer or 
sponsor may assert against Implementing Technologies based on such 
Contribution, must make a disclosure in accordance with this Section 
6. 


This requirement specifically includes Contributions that are made by 
any means including electronic or spoken comments, unless the latter 
are rejected from consideration before a disclosure could reasonably 
be submitted. An IPR discloser is requested to withdraw a previous 
disclosure if a revised Contribution negates the previous IPR 
disclosure, or to amend a previous disclosure if a revised 
Contribution substantially alters the previous disclosure. 


Contributors must disclose IPR meeting the description in this 
section; there are no exceptions to this rule. 


6.1.2. An IETF participant’s IPR in Contributions by others 


Any individual participating in an IETF discussion who reasonably and 
personally knows of IPR meeting the conditions of Section 6.6 which 
the individual believes Covers or may ultimately Cover a Contribution 
made by another person, or which such IETF participant reasonably and 
personally knows his or her employer or sponsor may assert against 
Implementing Technologies based on such Contribution, must make a 
disclosure in accordance with this Section 6. 


6.1.3. IPR of others 


If a person has information about IPR that may Cover IETF 
Contributions, but the participant is not required to disclose 
because they do not meet the criteria in Section 6.6 (e.g., the IPR 
is owned by some other company), such person is encouraged to notify 
the IETF by sending an email message to ietf-ipr@ietf.org. Such a 
notice should be sent as soon as reasonably possible after the person 
realizes the connection. 


6.2. The timing of providing disclosure 
Timely IPR disclosure is important because working groups need to 


have as much information as they can while they are evaluating 
alternative solutions. 
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6.2.1. Timing of disclosure under Section 6.1.1 


The IPR disclosure required pursuant to section 6.1.1 must be made as 
soon as reasonably possible after the Contribution is published in an 
Internet Draft unless the required disclosure is already on file. 

For example, if the Contribution is an update to a Contribution for 
which an IPR disclosure has already been made and the applicability 
of the disclosure is not changed by the new Contribution, then no new 
disclosure is required. But if the Contribution is a new one, or is 
one that changes an existing Contribution such that the revised 
Contribution is no longer Covered by the disclosed IPR or would be 
Covered by new or different IPR, then a disclosure must be made. 


If a Contributor first learns of IPR in its Contribution that meets 
the conditions of Section 6.6, for example a new patent application 
or the discovery of a relevant patent in a patent portfolio, after 
the Contribution is published in an Internet-Draft, a disclosure must 
be made as soon as reasonably possible after the IPR becomes 
reasonably and personally known to the Contributor. 


Participants who realize that a Contribution will be or has been 
incorporated into a submission to be published in an Internet Draft, 
or is seriously being discussed in a working group, are strongly 
encouraged to make at least a preliminary disclosure. That 
disclosure should be made as soon after coming to the realization as 
reasonably possible, not waiting until the document is actually 
posted or ready for posting. 


6.2.2. Timing of disclosure under Section 6.1.2 


The IPR disclosure required pursuant to section 6.1.2 must be made as 
soon as reasonably possible after the Contribution is published in an 
Internet Draft or RFC, unless the required disclosure is already on 
file. Participants who realize that the IPR will be or has been 
incorporated into a submission to be published in an Internet Draft, 
or is seriously being discussed in a working group, are strongly 
encouraged to make at least a preliminary disclosure. That 
disclosure should be made as soon after coming to the realization as 
reasonably possible, not waiting until the document is actually 
posted or ready for posting. 


If a participant first learns of IPR that meets the conditions of 
Section 6.6 in a Contribution by another party, for example a new 
patent application or the discovery of a relevant patent in a patent 
portfolio, after the Contribution was published in an Internet-Draft 
or RFC, a disclosure must be made as soon as reasonably possible 
after the IPR becomes reasonably and personally known to the 
participant. 
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6.3. How must a disclosure be made? 


IPR disclosures are made by following the instructions at 
http://www.ietf.org/ipr-instructions. 


6.4. What must be in a disclosure? 

6.4.1. The disclosure must list the numbers of any issued patents or 
published patent applications or indicate that the claim is based on 
unpublished patent applications. The disclosure must also list the 


specific IETF or RFC Editor Document(s) or activity affected. If the 
IETF Document is an Internet-Draft, it must be referenced by specific 
version number. In addition, if the IETF Document includes multiple 
parts and it is not reasonably apparent which part of such IETF 
Document is alleged to be Covered by the IPR in question, it is 
helpful if the discloser identifies the sections of the IETF Document 
that are alleged to be so Covered. 


6.4.2. If a disclosure was made on the basis of a patent application 
(either published or unpublished), then, if requested to do so by the 
IESG or by a working group chair, the IETF Executive Director can 
request a new disclosure indicating whether any of the following has 
occurred: the publication of a previously unpublished patent 
application, the abandonment of the application and/or the issuance 
of a patent thereon. If the patent has issued, then the new 
disclosure must include the patent number and, if the claims of the 
granted patent differ from those of the application in manner 
material to the relevant Contribution, it is helpful if such a 
disclosure describes any differences in applicability to the 
Contribution. If the patent application was abandoned, then the new 
disclosure must explicitly withdraw any earlier disclosures based on 
the application. 


New or revised disclosures may be made voluntarily at any time. 


6.4.3. The requirement for an IPR disclosure is not satisfied by the 
submission of a blanket statement of possible IPR on every 
Contribution. This is the case because the aim of the disclosure 
requirement is to provide information about specific IPR against 
specific technology under discussion in the IETF. The requirement is 
also not satisfied by a blanket statement of willingness to license 
all potential IPR under fair and non-discriminatory terms for the 
same reason. However, the requirement for an IPR disclosure is 
satisfied by a blanket statement of the IPR discloser’s willingness 
to license all of its potential IPR meeting the requirements of 
Section 6.6 (and either Section 6.1.1 or 6.1.2) to implementers of an 
IETF specification on a royalty-free basis as long as any other terms 
and conditions are disclosed in the IPR disclosure statement. 
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6.5. What licensing information to detail in a disclosure. 


Since IPR disclosures will be used by IETF working groups during 
their evaluation of alternative technical solutions, it is helpful if 
an IPR disclosure includes information about licensing of the IPR in 
case Implementing Technologies require a license. Specifically, it 
is helpful to indicate whether, upon approval by the IESG for 
publication as RFCs of the relevant IETF specification(s), all 
persons will be able to obtain the right to implement, use, 
distribute and exercise other rights with respect to an Implementing 
Technology a) under a royalty-free and otherwise reasonable and non- 
discriminatory license, or b) under a license that contains 
reasonable and non-discriminatory terms and conditions, including a 
reasonable royalty or other payment, or c) without the need to obtain 
a license from the IPR holder. 


The inclusion of licensing information in IPR disclosures is not 
mandatory but it is encouraged so that the working groups will have 
as much information as they can during their deliberations. If the 
inclusion of licensing information in an IPR disclosure would 
Significantly delay its submission it is quite reasonable to submit a 
disclosure without licensing information and then submit a new 
disclosure when the licensing information becomes available. 


6.6. When is a disclosure required? 


IPR disclosures under Sections 6.1.1. and 6.1.2 are required with 
respect to IPR that is owned directly or indirectly, by the 
individual or his/her employer or sponsor (if any) or that such 
persons otherwise have the right to license or assert. 


7. Failure to disclose 


There are cases where individuals are not permitted by their 
employers or by other factors to disclose the existence or substance 
of patent applications or other IPR. Since disclosure is required 
for anyone submitting documents or participating in IETF discussions, 
a person who does not disclose IPR for this reason, or any other 
reason, must not contribute to or participate in IETF activities with 
respect to technologies that he or she reasonably and personally 
knows to be Covered by IPR which he or she will not disclose. 
Contributing to or participating in IETF discussions about a 
technology without making required IPR disclosures is a violation of 
IETF process. 
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8. 


Evaluating alternative technologies in IETF working groups 


In general, IETF working groups prefer technologies with no known IPR 
claims or, for technologies with claims against them, an offer of 
royalty-free licensing. But IETF working groups have the discretion 
to adopt technology with a commitment of fair and non-discriminatory 
terms, or even with no licensing commitment, if they feel that this 
technology is superior enough to alternatives with fewer IPR claims 
or free licensing to outweigh the potential cost of the licenses. 


Over the last few years the IETF has adopted stricter requirements 
for some security technologies. It has become common to have a 
mandatory-to-implement security technology in IETF technology 
specifications. This is to ensure that there will be at least one 
common security technology present in all implementations of such a 
specification that can be used in all cases. This does not limit the 
specification from including other security technologies, the use of 
which could be negotiated between implementations. An IETF consensus 
has developed that no mandatory-to-implement security technology can 
be specified in an IETF specification unless it has no known IPR 
claims against it or a royalty-free license is available to 
implementers of the specification unless there is a very good reason 
to do so. This limitation does not extend to other security 
technologies in the same specification if they are not listed as 
mandatory-to-implement. 


It should also be noted that the absence of IPR disclosures is not 
the same thing as the knowledge that there will be no IPR claims in 
the future. People or organizations not currently involved in the 
IETF or people or organizations that discover IPR they feel to be 
relevant in their patent portfolios can make IPR disclosures at any 
time. 


It should also be noted that the validity and enforceability of any 
IPR may be challenged for legitimate reasons, and the mere existence 
of an IPR disclosure should not automatically be taken to mean that 
the disclosed IPR is valid or enforceable. Although the IETF can 
make no actual determination of validity, enforceability or 
applicability of any particular IPR claim, it is reasonable that a 
working group will take into account on their own opinions of the 
validity, enforceability or applicability of Intellectual Property 
Rights in their evaluation of alternative technologies. 
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Ds 


10. 


11. 


Change control for technologies 


The IETF must have change control over the technology described in 
any standards track IETF Documents in order to fix problems that may 
be discovered or to produce other derivative works. 


In some cases the developer of patented or otherwise controlled 
technology may decide to hand over to the IETF the right to evolve 
the technology (a.k.a., "change control"). The implementation of an 
agreement between the IETF and the developer of the technology can be 
complex. (See [RFC 1790] and [RFC 2339] for examples.) 


Note that there is no inherent prohibition against a standards track 
IETF Document making a normative reference to proprietary technology. 
For example, a number of IETF Standards support proprietary 
cryptographic transforms. 


Licensing requirements to advance standards track IETF Documents 
RFC 2026 Section 4.1.2 states: "If patented or otherwise controlled 


technology is required for implementation, the separate 
implementations must also have resulted from separate exercise of the 


licensing process." A key word in this text is "required." The mere 
existence of disclosed IPR does not necessarily mean that licenses 
are actually required in order to implement the technology. Section 


4.1 of this document should be taken to apply to the case where there 
are multiple implementations and none of the implementers have felt 
that they needed to license the technology and they have no plausible 
indications that any IPR holder(s) will try to enforce their IPR. 


No IPR disclosures in IETF Documents 


IETF and RFC Editor Documents must not contain any mention of 
specific IPR. All specific IPR disclosures must be submitted as 
described in Section 6. Specific IPR disclosures must not be in the 
affected IETF and RFC Editor Documents because the reader could be 
misled. The inclusion of a particular IPR disclosure in a document 
could be interpreted to mean that the IETF, IESG or RFC Editor has 
formed an opinion on the validity, enforceability or applicability of 
the IPR. The reader could also be misled to think that the included 
IPR disclosures are the only IPR disclosures the IETF has received 
concerning the IETF document. Readers should always refer to the 
on-line web page to get a full list of IPR disclosures received by 
the IETF concerning any Contribution. (http://www.ietf.org/ipr/) 
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14. 


Security Considerations 


This memo relates to IETF process, not any particular technology. 
There are security considerations when adopting any technology, 
whether IPR-protected or not. A working group should take those 
security considerations into account as one part of evaluating the 
technology, just as IPR is one part, but there are no known issues of 
security with IPR procedures. 
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16. Full Copyright Statement 


Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78 and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 

REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to 

rights in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use 
of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository 
at http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights that may cover technology that may be required 
to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org. 
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